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METHODS AND APPARATUS FOR 
EFFICIENTLY TRANSMITTING INTERACTIVE APPLICATION 
DATA BETWEEN A CLIENT AND SERVER USING MARKUP LANGUAGE 

FIELD OF THE INVENTION 

[0001] The present invention relates to client-server networks and, in particular, to 
methods and apparatus for remotely executing an application and displaying application 
output. 

BACKGROUND OF THE INVENTION 

[0002] Contemporary computer networks consist of a number of computer systems, 
called nodes, communicating v^th other computer systems via communication links. 
Typically, some of the nodes are client nodes and other nodes are server nodes. A client 
node formulates and delivers queries to a server node. A xiser of the client node enters the 
queries through a user interface operating on the client node. The server node evaluates 
the queries and delivers responses to the client node for display on the client user 
interface. 

[0003] Usually, the server nodes host a variety of application programs or processes 
that can be accessed and executed by client nodes. When a client node launches an 
application program, the execution of that application program can occur at either the 
client node or the server node, depending upon the computing model followed by the 
computer network. 
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[0004] In a client-based computing model, the application program is packaged and 
sent down to, or pre-installed on, the client node, allowing the client node to run the 
application using the resources of the client node. This approach has several drawbacks. 
First, the client node must have sufficient memory, disk space, and processing power to 
effectively execute the application. A related problem that occurs using this model is that 
the number of applications a given client is able to execute is limited due to client 
resoxzrce constraints. Further, applications built this way are complex to develop and 
maintain and typically require modification or "porting" for all supported client computer 
system types. Moreover, this technique exacerbates the administration burden on a 
network administrator. 

[0005] In a server-based computing model, the server node executes the application 
program, and only the control information for the client user interface is transmitted 
across the computer network to the client node for display. Using this approach, user 
interface events must be sent between the client and the server in order for the server 
application to process the events. This results in perceived delays of user interface 
response. Further, the application program must be specifically written, or changed, to 
support the user interface on the client node. This increases the complexity of the 
application and prevents this technique from being useful with off-the-shelf applications. 

[0006] A refinement of the server-based model is to supplant the device driver to 
which the appHcation communicates in order to send screen and device updates back and 



forth between the client and the server. This approach avoids requiring applications to be 
rewritten. However, this approach requires device information to be sent between the 
client and the server in order to maintain the client display, again introducing perceived 
latency into the interface. Further, server-side processing requirements are increased in 
order to satisfy resulting device information required for communication with each 
connected cUent. 

[0007] A recent, further refinement of the server-based model is to deploy the user 
mterface portion of the application as a mark-up language document such as Hyper Text 
Markup Language (HTML) document. However in using this approach, information sent 
from the server application to the client begins to "age" immediately. In other words the 
information may change on the server but the client would not automatically be notified 
and updated. Further, with this approach interactivity requires context switching between 
pages even to perform simple tasks. 
[0008] The present invention avoids these shortcomings. 

SUMMARY OF THE INVENTION 

[0009] The present invention provides a mechanism by which the user interface 
portion of the application can be delivered to the computer user either on the same 
machine on which the application is executing or on another machine remote from the 
machine executing the application. The invention separates the user interface from the 
underlying application enabling the user interactive portion of the application to be 
extremely simple. The mvention also permits the user interactive portion to be deployed 



on a wide range of client hardware environments without bringing with it all the required 
logic for performing the functionality of a particular application. These features give the 
user the effect of directly interacting with whole application even though the main part of 
the application is potentially running somewhere else. 

[00010] ThuSj the present invention overcomes many of the problems faced by 
traditional approaches outlined above. User interface, event handling and screen 
rendering logic stay on the client, thus dramatically reducing network traffic and latency. 
The entire user interface and how that interface connects to application components on 
the server are sent as a pure data description to the client (rather than code). This 
description is "interpreted" by the client to render the graphics user interface (GUI) and 
connect to the application (through the transfer of state) running either in the same 
process space (same machine) or on the server (remote machine). 
[00011] Because the server can communicate with a particular application client with 
simply a data description, no additional code needs to be installed on the cUent machine. 
An application-independent client process (AICP) reads the description and presents that 
description to the user as a typical client user interface. Therefore, the AICP can 
communicate with an unlimited number of server applications with a new data file 
description for each program (which can be cached automatically as required or as 
specified by the client). No application specific administration is required for executing 
an AlCP-deployed appUcation using this approach. 
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[00012] With the AICP, no server side processing is required to either render the user 
interface portion or handle the GUI events portion of the application. The server does, 
however, coordinate state mformation being passed to and from the client and sends that 
information automatically to the appropriate application components involved (both 
client and server initiated data changes). 

[00013] Using the AICP, the developer can focus primarily on the functional or 
business logic portion of the appUcation and let the AICP handle all of the user interface 
rendering, event handling, and connection of the user interface controls with the 
underlying application components. A builder component allows the developer to layout 
the user interface windows as well as create a relationship between the visual control and 
the underlying application server component with which it is associated. With the AICP 
no application specific code needs to be sent to the client. Only user interface controls 
need be sent if requked. Even though there is no code on the cUent, the user's experience 
with the client application is similar to hand-coded clients found in the client based mode. 
In one embodiment the AICP is embedded in an HTML browser environment which 
enables web deployment vdthin an HTML page without the limitation associated with 
HTML. 

[00014] The foregoing and other objects, features and advantages of the invention will 
be apparent from the following more particular description of the embodiments of the 
invention, as illustrated in the accompanying drawings. 



BRIEF DESCRIPTION OF THE DRAWINGS 

[00015] Fig. 1 is a block diagram of an embodiment of the system of the kivention; 

[00016] Fig. 2 is a block diagram of an embodiment of the memory configuration of a 
server constructed in accordance with the invention; 

[00017] Fig. 3 is an operational block diagram showmg an embodiment of the 
communications between a server and a client node constructed in accordance with the 
invention; 

[00018] Fig. 4 is a block diagram of an embodiment of the memory configuration of a 
client constructed in accordance with the invention; 

[00019] Fig. 5 is a flow diagram of an embodiment of the operation of the server 
constructed in accordance with the invention; and 

[00020] Fig. 6 is a flow diagram of an embodiment of the operation of the client node 
constructed in accordance with the invention. 

DETAILED DESCRIPTION OF THE INVENTION 

[00021] Although the method and apparatus of the present invention is described in the 
context of a web server and web browser process communicating over the Intemet, those 
skilled in the art will recognize that the present invention can also be practiced over any 
other type of network (e.g., telephone, cable, LAN, WAN, wireless, fiber), within the 
same physical computer system, or with portions of the invention (e.g. the application 



independent client process) operating in an Internet appliance or cable TV set-top box. 
For those individuals who are not familiar with the Internet, the world-wide web, web 
servers, and web browsers, a brief overview of these concepts is presented here. 
[00022] Referring to Figure 1 , a user that wishes to access information and execute 
applications on the Internet 120 typically has a computer workstation 110 that executes 
an application program known as a web browser 1 12. An application independent client 
process (AICP) 1 14, in accordance with the present invention, in one embodiment, is 
provided as a plug-in to the web browser 112, The user interacts with the web browser 
112 and AICP 1 14 via a user interface 116 that in one embodiment includes a data entry 
device (e.g.j a keyboard) and a visual display device (e.g., a computer monitor). Under 
the control of web browser 112, the user workstation 110 sends a web page request 122 
over the Internet 120. Web page data can be in the form of text, graphics and other forms 
of information. Each web server computer system 130 on the Internet 120 has a known 
address (a URL) which the user must supply to the web browser 1 12 in order to connect 
to the appropriate web server 130. Because web server 130 can contain more than one 
web page, the user will also specify in the address which particular web page 124 he or 
she wants to view on web server 130. The web server computer system 130 executes a 
web server application program 132, monitors requests, and services requests for which it 
has responsibility. When a request specifies web server 130, web server application 
program 132 generally accesses a web page 124 corresponding to the specific web page 
request 122, md transmits the web page 124 to the user workstation 1 10. The web page 



request 122 also includes, in one embodiment, a request to execute an application 
program on the web server computer system 130. An application independent server 
process (AISP) 134 receives information contained in this request and responds by 
executing the desired application program and accessing application components 136 that 
are needed by the AICP 1 14. 

[00023] In general, a web page contains the primary visual data displayed on the user 
interface 1 16 of the user workstation 110. When the web server 130 receives a web page 
request 122, it builds a web page in HTML and transmits it across the Internet 120 to the 
requesting web browser 1 12. Web browser 1 12 interprets the HTML and outputs the web 
page 124 to the monitor of the user workstation 110. The web page 124 displayed on the 
user's screen may contain text, graphics, and links (which are addresses of other web 
pages). These other web pages (i.e., those represented by links) may be on the same or on 
different web servers. The user can go to these other web pages by clicking on these 
links using a mouse or other pointing device. This entire system of web pages with links 
to other web pages on other servers across the world is known as the "World Wide Web". 
[00024] With the present invention, an interactive graphical user interface is embedded 
in the web page or may be brought up as a separate dialog from the web page. In one 
embodiment, the AICP is an ActiveX control embedded in the previously mentioned 
HTML page. The ActiveX control interprets XML data that is subsequently downloaded 
in a description file (described below) and renders a graphical user interface. This 
embedded control is an embodiment of the AICP. 
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[00025] Referring to Fig. 2, located in memory in the server system 130 is an 
operating system 410, a web server application 132, application programs 420, 
application components 136, a transaction processor 430, state information, object 
information, and data (not shown), and one or more instances of an AISP 134. 
[00026] The application programs 420 are executed by the CPU of the server system 
130 under the control of operating system 410. Application programs 420 can be 
executed using program data as input, such as that received from the AICP 1 14. 
Application programs can also output their results as program data in memory. 
[00027] The transaction processor 430 is a program that receives information from the 
web server application 132 via a common gateway interface (not shown), interprets the 
information to determine whether a specific instance of an AISP 134 is required, and 
launches the instance AISP 134 to ftirther process the request received from the AICP 
114. 

[00028] Referring to Figure 3, the present invention includes the AICP 11 4 and the 
AISP 134. The AICP 114 renders the graphical user interface (GUI) that is displayed to 
the user on the user interface 116. The AICP 114 also maintains a relationship between 
the control objects displayed on the user interface 116 and the application components 
136 maintained on the web server 130. The AISP 134 tracks the state of the application 
components 136 along with the control objects displayed on the user workstation 110 that 
require updates of these application components. Whenever the state changes on either 
the client (control state) or the server (component state), the AICP 114 and AISP 134 take 
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appropriate action based on the data description that defines the relationship between the 
GUI controls and the server application components 136 (hereafter referred to as server 
components) they represent. 

[00029] Referring also to Fig. 4, the relationship 446 between the control objects 624 
displayed on the user interface 1 16 of the user workstation 1 10 and the server 
components 136 maintained on the web server 130 mclude data that describes an explicit 
relationship between their respective object interfaces. This data v^U hereafter be 
referred to as a connection. The AICP and AISP contain logic that can interpret 
cormections that relate a visual control to an application component. 
[00030] For example, a scroll bar control is representative of a type of control object 
that can be displayed on the user interface 1 16 of the user workstation 1 10. The scroll bar 
control can be associated with the value of an application component, such as the 
temperature of an industrial process. As the server application detects a temperature 
change, the state of the Application Components 136 is changed and these state changes 
330 are forwarded to the client. The scrollbar is subsequently redrawn by the AICP to 
reflect the new value. Likev^se, if a scroll bar is coimected to an Application Component 
136 that controls a thermostat, then when the user interacts with the scroll bar on the user 
interface 1 16, the state change is transmitted to the Web Server Application Program 132 
which would change the state of the appropriate Application Component 136 which 
would subsequently set the thermostat. 
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[00031] Although this is a simple example, comiections can fomi relationships (e.g., 
data relationships 446 in Fig. 2) between very complex object types Hke composite 
components (components that contain component references) as well as component 
collections (a hst of components). Controls can be tied (connected) to complex 
components or a composite of controls (commonly referred to as a dialog). The more 
complex the relationship 446 (Fig. 2) the more verbose the connection information. 
However, connection information can be packaged as a named entity, which can be 
referred to in another context so that connection reuse is possible. 
[00032] A physical connection exists between the AICP 1 14 and AISP 134. This 
physical connection can be either network based (server and client being different nodes 
on a network) or memory based (server and client being on the same computer system). 
This means that control objects can be connected to server components where they both 
exist on the same or different physical machines (as well as the same process on the same 
machine or different processes on different machines). 

[00033] The connection information can be delineated in a description file in a variety 
of formats, such as in XML format as discussed below. The XML data also includes the 
GUI layout description (i.e., user interface data 448 in Fig. 2). Whenever a control object 
624 is associated to a server component 136 within a GUI layout (a dialog window), the 
connection description is included (in context) with the layout information. This is the 
information the AICP 114 uses to run the application and display the results to the user. 
Once a dialog is running via the AICP 114, state changes that occur on either the control 
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objects (control states) or server components (component state 442, Fig. 2) are packaged 
and sent between the AICP 1 14 and AISP 134. This is a two-way connection and is 
asynchronous to minimize interactive latency. 

[00034] The description file can be in an XML format, which is a convenient format 
for deployment of data over a network and resembles an attributed file structure, for 
example as shown in the Appendix. A number of other suitable database formats are also 
available, such as flat file, SQL, OODB, etc. The XML format consists of name, type, 
and value pairs, which allow both the AICP 114 and the AISP 1 34 to traverse and 
interpret the information in the same file format during runtime. The XML file that is 
interpreted by the client and AISPs at runtime can be identical. The data contained in the 
XML file will be interpreted differently by the AICP 1 14 and AISP 134 in accordance 
with the different functions that need to be performed on each side of the connection. 
Although the description file is discussed herein as being located on the same computer 
systems as the AICP 1 14 and AISP 134, those skilled in the art will recognize that the 
description file can be located in any networked location that is accessible by the AICP 
and AISP. 

[00035] Referring to Figs. 2, and 4, the AISP 134 performs the foUovraig fimctions: 
sends the XML data stream to the AICP 1 14, reads the description file 310 (Fig. 3) ( 
which can be transmitted as an XML data stream), responds to requests from the AICP 
1 14 to attach to server components 136, maintains a stateful connection, and tracks 
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context on the web server 130. Note that multiple AISPs 134' can exist in the memory of 
the web server 130 at any given time. 

[00036] In use, and referring to Fig. 5, a developer first designs (step 710) the layout of 
the user interface 1 16 that will ultimately be displayed on the user workstation 110 and in 
so doing establishes the relationships between the control objects 624 (Fig. 4) and the 
server components 136. Once this information is formulated, it is stored (step 712) in a 
description file 310. When the AICP 1 14 transmits a request to execute an application 
program 420 on the web server 130, the transaction processor 430 (Fig. 2) receives (step 
714) the request, instantiates (step 718) an AISP 134 associated with the application 
program 420 if an instance is not already loaded in memory, and launches (step 720) the 
application program 420. Once the AICP 1 14 receives the description file 310, it 
transmits a connection request to the AISP 134. The AISP 134 receives (step 722) the 
connection request and loads (step 724) the description file 310 associated with the 
requested application program 420 into server memory. 

[00037] The description file 3 1 0 associated with the requested application program 
420 is loaded in order to connect the AICP 1 14 with the appropriate server components 
1 36. The description file 3 1 0 contains sufficient information vdth respect to the 
relationships between control objects 624 (Fig. 4) and server components 136 to enable 
the AISP 134 to manage the server components and the AICP 1 14 to manage the control 
objects. 
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[00038] Upon loading the description file 3 1 0, the AISP 1 34 forms (step 726) a 
manager object 452 for each server component 136 that will likely be mvolved in that 
client/server connection. In addition a unique manager object is created (step 728) for 
each control that could be instantiated on the client (referred to as the Meta object 454) as 
well. The Meta object 454 stores data such as member information, dialog information, 
connection information, object-to-object connection information, and a reference to a 
client manager component in order to effectively connect control objects 624 to server 
components 136. 

[00039] Member information includes the properties, functions, and events available 
on the interface of a control object. This information is used to tell a connection handler 
450 how to communicate with particular control objects (as well as server components) 
involved in the connection during runtime. Dialog information is the GUI layout 
information that is used by the AICP 1 14 to render the user interface 1 16 on the user 
workstation 110. The dialog information also specifies the type of control object 624 or 
server component 136 that will be mvolved in the connection. Connection information 
describes how a particular control object 624 is associated with a particular server 
component 136. Object-to-object connection information provides a connection 
description that enables a client to server component connection and a server component 
to server component connection. This allows server components to communicate with 
each other without knowing any specific details of the objects they are connected to. 
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[00040] The client manager component provides a standard interface allowing the 
AISP 134 to talk to the back end application program 420. The client manager is a 
component interface that must be implemented by the server application program 420 in 
order to initialize the behavior of the AICP 1 14. The client manager component 
interface, in one embodiment, includes 4 functions: ClientCanConnectQ, 
ClientCanDisconnectO, ClientConnectedQ, ClientDisconnectedQ. These functions are 
called whenever a new AICP 1 14 wants to connect or disconnect an application program 
420 on the web server 130. 

[00041] When a dialog is created in the AICP 1 14, the AISP 134 is notified tiiat it 
must create a physical attachment to the relevant instance of the server component 136 on 
the server 130. In order to establish this physical attachment, the AISP 134 maps (step 
732) the object controls in the user interface 1 16 to server components 136. The dialog 
description of the server component 136 can be found in the Meta object 454. At this 
point the AISP 134 obtains the name of the dialog that is to be created on the AICP 1 14 
and receives access to an instance of server component 136. A connection handler 450 is 
instantiated for each control that requires connection to a part of the server component 
instance. The connection handler 450 initializes and maintains the cormection between 
the control object 624 and server component 136. Only connection handlers 450 that are 
marked as "run on the server" would be created at this point. If they were marked as "run 
on the client" then the AICP 1 14 would have already created one. The connection 
handler 450 is assigned an identifier 618 (Fig. 4) that is identical to that provided for the 
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control object 624 of the AICP 1 14. This identifier 618 is used to synchronize the 
information messages going back and forth between the AICP 1 14 and the AISP 134. 
[00042] Similar to the dialog object described in the AICP section, the server forms 
(step 730) a cUent-side proxy object 456 that arbitrates messages sent between the client 
side of the server connection and the AICP 1 14. The connection handler 450 
communicates with this proxy object 456 as if it were the control object 624 itself The 
proxy object 456 transmits a value for the control object 624 to the AICP 1 14 which in 
tum will modify the control object 624 on the user interface 116. In this manner, the 
proxy object 456 can transmit initial state information to the AICP 1 14 (step 734) as well 
as updating the AICP 1 14 with state changes 330 of a particular server component 136 on 
the server 130 (step 738). Similarly, when the control state 622 of a control object 624 on 
the AICP 1 14 changes, the modified control state is sent to the AISP (using the control 
identifier 618 assigned to that particular control object 624) via the proxy object 456. 
Once the modified control state had been received by the proxy object 456, the proxy 
object 456 notifies the connection handler 450 that the state of the control object has 
changed so that the modified state can be incorporated into the appropriate server 
component 136. 

[00043] Similar to the AICP 1 14, the AISP 134 maintains (step 736) the connection 
for the duration of the dialog. When the dialog is closed by the user, or via some other 
fashion (e.g., a notification by a server component to close all connected dialogs), the 
AISP 134 removes and deletes each of the connection handlers 450 associated with the 



16 



connection to the dialog. In addition, tihe proxy objects 456 used to communicate on 
behalf of the control objects 624 are discarded as well 

[000441 The AISP 134 uses a component manager (not shown) to maintain a list of 
components involved in client side connections. The component manager keeps track of 
all the dialogs that are actively attached to server components for the duration of the 
dialog. Each time a dialog is created on an AICP 1 14, a reference to the dialog is added 
to the list maintained by the component manager. This reference identifies all of the 
server side connection handlers, which in tum reference control proxies involved in a 
connection. When a dialog is closed, the AISP 134 refers to this list to lookup the dialog 
connection information and removes the dialog reference from the list. 
[00045] Although the AICP 1 14 and AISP 134 perform different roles, much of their 
respective code is identical. The key to making both the AICP and AISP nearly identical 
is in providing a standard object interface that connects control objects 624 on the AICP 
1 14 and server components 136 on the AISP 134. The interpreter logic of the application 
independent processes can connect each respective side (client or server) in exactly the 
same way (through a standard object interface). The fact that the control object is visual 
is just a side affect of the implementation of the object. Therefore, the present mvention 
can be applied to a number of implementations that do not require a visual presentation. 
[00046] Referring again to Fig. 4, the AICP 1 14 can reside in the memory of the user 
workstation 110. The memory also holds the operating system 612 installed on the user 
workstation 110 and the web browser application program 1 12 within which the AICP 
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1 14 is launched. The AICP 1 14 performs the following functions: reads the data 
description file 310, renders the user interface 1 16, attaches connected controls, maintains 
a stateful connection, and tracks the context on the client. 

[00047] Referring also to Fig. 6, the AICP 1 14 is first installed on the user workstation 
1 10. The most common installation method is to manually install the AICP 1 14 through 
the system install procedure (e.g., in the Microsoft Windows operatmg system, using the 
"Add/Remove Programs" function). Alternatively, the AICP 1 14 can be automatically 
installed through a web based plug-in protocol. 

[00048] Because there is no code on the client that represents the application program 
420, the AICP 1 14 supports a number of approaches in establishing the initial connection 
to the server side appUcation program 420. The information required by the AICP 1 14 to 
interact with the application program 420 includes: the name of the server process to 
execute, the location of the description file 310 on a network server, any initial arguments 
that must be communicated to the application program 420 when connected, and the 
current version of the description file. This information can be contained in an 
initialization file that is loaded when the AICP 1 14 is laimched. 
[00049] When the AICP 1 14 is started, it will access (step 8 1 0) the initialization file 
and, using the information contained therein, will transmit a request to the server 134 to 
run the desired application program 420. As previously discussed, the transaction 
processor 430 on the server 130 sends a description file 310 to the AICP 1 14 which then 
compares the version stamp of the description file received to that contained in the local 
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memory 610 of the user workstation 1 10 (obtained from a prior transaction or during 
installation of the AICP 1 14), The AICP 1 14 can then determine (step 812) which 
version of the description file 310 to load. By default, the AICP 1 14 only downloads the 
description file 310 from the transaction processor 430 if the version stamp of the file on 
the server is later than a cached file afready resident on the client. The description file 
310 is peculiar to a specific application program 420. 

[00050] Once downloaded (or loaded locally from a file cache), the description file 
310 provides the AICP 1 14 with the dialog description of the application program 420. 
The AICP 1 14 then proceeds to interpret (step 814) the description data of that dialog in 
order to construct the control objects 624 that exist within the dialog and lay out the 
control objects 624 onto the user interface 1 16 for presentation to the user. 
[00051] Meanwhile, tiie AICP 1 14 transmits a request (step 8 1 6) to the AISP 1 34 to 
estabUsh a logical connection to the server components 136. Upon successfiilly 
connecting to the server components 136 on tiie server 130, the AICP 1 14 receives (step 
818) and subsequently populates tiie dialog control objects 624 with control state 
information 622 corresponding to the server component state 442. 
[00052] State changes for a particular visual context (e.g., a dialog) are sent to tiie 
AICP 1 14 as one logical packet for optimization reasons, although the structure of the 
state change packet is identical regardless if a single state change or a plurality of state 
changes occurred. At this point, the control objects 624 are actively connected to the 
server components 136 so that state changes on either side are reflected in the other. Once 
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the control objects 624 reflect the current server component state 442, the dialog is then 
displayed (step 820) to the user via the user interface 116. 

[00053] Control objects 624 are associated v^ith the server components 136 by a 
reference property that is provided as part of the description of the control object 624, 
which is included in the overall dialog layout description. This reference can be the name 
assigned to the connection description and the type of the associated server component 
136. A unique control identifier 618 is computed for each of the control objects 624 that 
are connected to server components 136. This control identifier 618 is used to coordinate 
state changes 330 with the AISP 134 when connecting to the appropriate server 
component instance that is assigned to that control object 624. Note that many control 
objects can be tied to the same server component 136 

[00054] Since the AICP 1 14 and the AISP 134 are largely identical processes, some of 
the connections can reside on the client. At times, it is useful to instantiate the 
connection logic that binds a client's control object 624 to a server's application 
component 136 on either the AICP 1 14 or the AISP 134. The selection of where to 
instantiate the connection logic depends on the volume of information flow coming into 
each side of the connection. For example, if the load is heaviest on the client side, then it 
is better to instantiate the connection handler on the client. In this way, bandwidth 
utilization can be tailored based on the kind of connection and the client and server 
components involved. 
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[00055] For as long as a dialog is displayed on a particular AICP 1 14, the connection 
handlers 450 maintain (step 822) a real time stateful connection to the associated server 
components 136. The connection handler 450 responds to state changes 330 on either the 
client control object 624 or on its associated server component 136. The connection 
handler 450 is also able to transform the data based on a set of rules defined by the 
developer. The connection handler 450 is able to maintain state on each side of the 
coimection by maintaining (step 822) references to the control objects 624 involved in the 
connection. 

[00056] The connection handler 450 also maintains a stateful connection whenever a 
member of a complex component changes. This happens when a property (which is a 
member of a complex component which can hold a value of a particular type or be 
empty) of a complex control is assigned a new value (which itself can be a complex or 
simple component). When the connection handler 450 detects a property change, it 
executes the appropriate connection transformation. In addition, if a control object 624 
was attached to that property it would not be connected to the new value. The connection 
handler involved would remove the reference to the old value and create a reference to 
the newly assigned value (of the property). In this manner, the control objects 624 are 
updated (step 824) with state changes 330 that are received from the AISP 134 and the 
state changes occurring in a control object 624 are transmitted (step 826) to the AISP 134 
in order to update the appropriate server components 136. 
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[00057] A GUI application involves several relationships that describe the user access 
to the underlying application. For example, a dialog can contain a button (which is an 
example of a control object), that when selected will popup another dialog. It is 
important for the AICP 1 14 and AISP 134 to actively maintain this context with the 
server components 136. A popup dialog usually represents a complex property member 
of a complex component. Another popup scenario is when the popup dialog provides an 
argument to a function that is a member of a complex component. These data 
relationships 446 represent application context that is tracked by the AIP, thereby freeing 
the developer from having to explicitly create and maintain them. 
[00058] The AICP 1 14 creates a container object for each dialog that is created on the 
user workstation 1 10. This container object tracks the duration of the dialog with respect 
to the server component 136, The container object detects when the dialog is closed by 
the user and takes appropriate action for closmg down the connection handlers 450 
associated with the control objects 624 within the dialog. The container object also 
coordinates processing of state change messages that flow between the AICP 1 14 and the 
AISP 134. Whenever the container object receives a state change 330 from the AISP 
134, it extracts the control identifier 618 contained in the message, locates the control 
objects 624 associated with that control identifier 618, and uses the component interface 
of the control object 624 to effect the state change directly on the control object 624. 
Likewise when the control object 624 changes state, the container object is notified of the 
change, packages up the state change message, and sends it to the AISP 134. 
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[00059] The container object sends state changes to the AISP 134 for the parts of the 
control object's interface in which the connection handler 450 is interested. The 
connection handler 450 is interested in the control members delineated in the description 
file 310 that were used to create the connection handler 450, The container object that 
wraps the dialog also creates an object container for each control object 624 instantiated 
within the dialog in order to maintain its statefiil lifetime. 

[00060] Both the AICP 1 14 and AISP 134 have container objects that manage the state 
of the components to which they are connected. These containers track the state of the 
objects as well as the application context in which these objects reside. The application 
context refers to the manner in which objects are referenced by the AICP 1 14 and the 
AISP 134. For example, when a dialog is connected to a server component 136, the 
AICP 1 14 creates a container for the dialog and the AISP 134 creates a container for the 
server component 136. When the user closes the dialog, the client container detects this 
action and notifies the server container. Each container can then take appropriate action 
based on the type of operation. The nature of the containers are hierarchical in that each 
container can hold other containers based on the complexity of the objects involved in a 
particular connection. 

[00061] There are two types of client containers - a dialog container and a control 
container. The dialog container manages the life of the dialog and the control container 
manages the flow of state ijoformation to the individual control. These containers enable 
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the attachment of the user interface elements to server side objects as well as maintaui the 
state integrity during the life of the connection. 

[00062] The dialog container is an object that is created for each window displayed on 
the user interface 1 16. The dialog container is created in accordance with the XML 
description in the description file 310. The dialog container processes the XML 
description and creates the dialog layout as well as the control objects contained within 
the description. In addition, the dialog container creates a control container for any 
controls that are connected to data on the server. Controls that are created for display 
purposes only do not need a control container (for example, a label or bitmap decoration). 
[00063] The dialog container supports several functions, including: rendering the 
window itself, creating the control containers as needed, notifying the AISP 134 when the 
dialog is closed and deleting subordinate control container objects, and closing child 
dialogs that depend from parent dialogs as appropriate. 

[00064] The control container is created for each control object 624 that is tied to data. 
The control container computes and holds a unique control identifier 618 that is used to 
send messages to the AISP 134 and to access the appropriate server components 136. 
When the AISP 134 initially transmits state data to the AICP 1 14, the control container 
sets the state on the control object 624 during initialization. The control container also 
receives state change messages during the connection life of the control object 624 and 
updates the control object 624 in accordance therewith. When the state of the control 
object 624 changes, the control container detects the change and sends a state change 
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message to the appropriate server element via the AISP 134 (using the control identifier 
61 8 and an identifier of the AISP instance). It is noteworthy that only the control 
container processes the state changes that are involved in a connection description and 
that most state changes on the control object 624 do not involve the connection, thus 
reducing unnecessary network traffic. 

[00065] In addition to the control containers, there are two kinds of server containers - 
component containers and member containers. For as long as the client dialog is open, 
the server component container maintains a reference to the underlying component 
instance that the client is connected to. The member container manages the flow of state 
information on the individual member of the component (similar to function and 
property). These containers enable the attachment of the user interface elements to client 
side control objects as well as maintain the state integrity during the life of the 
connection. 

[00066] A component container is created by the AISP 134 for each server component 
136 that is connected to a client dialog. The component container adds a reference covint 
to the server component 136 so that it will not be lost during the life of the remote client 
dialog. For each member of the server component 136 that is involved in a connection to 
a control object 624, a member container object is created which will be responsible for 
maintaining the member's state during the life of the connection. When the dialog is 
closed on the client, the component container destroys all the child member containers 
that were used to maintain that dialog's connection on the server. 
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[00067] A member container is created for each member of a server component 136 
that is involved in a connection to a control object 624. The member container computes 
and stores a imique control identifier that is used to send messages to the AICP 1 14 in 
order to access the correct control object 624. The member container also sends initial 
state information to the control object 624 during the initialization of the dialog. Further, 
the member container receives data change message from the AICP 114 and updates the 
appropriate member of the server component 136 in accordance therewith. 
[00068] Whenever the state of the component member changes, the member container 
detects the change and subsequently sends a message, containing the state change 
information, to the appropriate control object 624 (using the control identifier 618 and the 
server instance identifier). It is noteworthy that only the member container processes the 
state changes that are involved in connection description and that most of the state 
changes on the server are not involved in a connection, thus reducing unnecessary 
network traffic. 

[00069] One of the capabilities of the AIP invention is its ability to allow multiple 
AICPs to attach to the same AISP. The first time that a client requests a connection to a 
server, an AISP assigned to the application will be instantiated. The AISP in turn 
instantiates the client manager object for that application. At any time, another client caa 
request to attach to the same application instance on the server. Instead of instantiating 
another AISP for that application, the same AISP instance will be used (as well as the 
client manager that was created for it). If two clients are then accessing the same server 
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component instance on the server, they will be able to interact and access the same state. 
This allows real time collaborative access to shared state that is not easily provided with 
traditional forms of client deployment . 

[00070] With collaboration deployment, a list of dialogs running on a particular client 
is associated with a client manager object that resides on the server. A list of client 
managers resides within the AISP (that reflects the current number of active clients 
attached to the same server application). Even though many clients can see the same 
information on the server they do not always have to view exactly the same components 
in the same way. The client manager can direct different clients to have different dialog 
representations of the same server components. Also, based on the client user's 
navigation through their own dialog instances, each client user may see dramatically 
different information at any given time. 

[00071] The present invention may be provided as one or more computer-readable 
programs embodied on or in one or more articles of manufacture. The article of 
manufacture may be a floppy disk, a hard disk, a CD ROM, a flash memory card, a 
PROM, a RAM, a ROM, or a magnetic tape. In general, the computer-readable programs 
may be implemented in any programming language. Some examples of languages that 
can be used include C, C++, or JAVA. The software programs may be stored on or in 
one or more articles of manufacture as object code. 

[00072] While the invention has been particularly shown and described with reference 
to several exemplary embodiments thereof, it will be understood by those skilled in the 
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art that varioxis changes in form and detail may be made therein without departing from 
the spirit and scope of the invention. 
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